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SECTION  1. 


INTRODUCTION 


This  report.  CDRL  COOS,  describes  the  results  of  Rome  Air  Development  Center  (RADC)  Contract 
F30602-88-D-0017.  entitled  Land  Analysis  Support  System  (LASS).  The  contract  was  performed  by  PAR 
Government  Systems  Corporation  (PGSC)  between  13  July  1990  and  30  December  1990. 

1.1.  Back(-round 

The  Land  Analysis  Support  System  (LASS)  is  an  integrated  hardware/sottware  complex  designed  to 
provide  the  means  to  create  Landsat  Image  Maps  for  regions  of  the  world  that  are  beyond  the  near  term 
DMA  production  plans.  In  addition,  it  provides  a  testbed  environment  for  the  development  of  new 
techniques  in  image  processing.  The  LASS  resides  at  DMA’s  Hydrographic/Topographic  Center. 

1.2.  Design  Summary 

The  remainder  of  this  report  is  organized  as  follows;  Section  2  provides  an  overview  of  the  LASS  including 
a  short  discussion  of  its  place  in  the  overall  image  mapping  production  process.  Section  3  describes  the 
LASS  design  including  modifications  that  were  made  to  the  lEF/RWPF  environment  to  enable  LASS 
capabilities,  additions  to  the  lEF  hardware  configuration  to  provide  a  proof  plot  generation  capability,  and 
the  development  of  software  to  generate  image  map  files  in  formats  for  importation  to  a  SCITEX 
environment.  Swtion  4  summarizes  LASS  developments  and  suggests  some  future  directions  to 
improve  the  lEF/LASS  image  map  generation  capabilities.  Appendix  A  describes  a  prototype 
development  activity  to  'engrave'  corrtour  information  on  LASS  produced  image  maps.  Appendix  B 
describes  the  steps  that  would  be  required  to  convert  the  current  LASS  environment  back  to  the  Unix- 
based  RWPF  environment.  Appendix  C  describes  the  steps  required  to  enable  a  high  resolution  display 
capability. 

1.3.  References 

The  following  documents  of  the  issue  shown,  form  a  part  of  this  final  report.  In  the  event  of  a  conflict 
between  the  documents  referenced  herein,  and  the  content  of  this  final  report,  the  content  of  this  final 
report  shall  be  considered  a  superseding  requirement. 

1.3.1.  Government  Documents 

DOO  STD  7935  -  1 5  February  1983 


LASS  Operations  Manual 


1.3.2. 


Non>Government  Documents 


LAS  Version  5.0  Documentation;  USGS  EROS  Data  Center  Sioux  Falls.  South  Dakota; 

LAS  Programmer's  Manual;  Febmary  1990 
DMS  Functional  Overview; 

Overview  of  the  Land  Analysis  System:  January  1990 

Overview  of  the  LAS  Display  Management  Subsystem;  January  1990 

Large  Area  Mosaicking  System  Documentation;  USGS  EROS  Data  Center.  Sioux  Falls  South  Dakota: 
Overview  of  the  Large  Area  Mosaicking  System;  August  1989 

SCITEX  Handshake  Foreign  File  Transfer  Protocol.  Scitex  Document  No.  788-37898A.  revision  A:  April 
1988 

Guide  to  Maintaining  a  VMS  System.  Version  5.0,  Digital  Equipment  Corporation,  oraer  number  AA- 
LA34A-TE;  Apnl  1988 

Guide  to  VMS  Performance  Management.  Version  5.0,  Digital  Equipment  Corporation,  order  number  AA- 
LA43A-TE;  April  1988 

Guide  to  Setting  Up  a  VMS  System.  Version  5.0.  Digital  Equipment  Corporation,  order  number  AA- 
LA25A-TE;  April  1988 

VMS  Installation  and  Operations:  VAX-i  1/780,785,  Version  5.0.  Digital  Equipment  Corporation,  order 
number  AA-LB29A-TE;  April  1988 

VMS  Version  5.0  Release  Notes.  Digital  Equipment  Corporation 
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SECTION  2. 


SYSTEM  OVERVIEW 


The  Land  Analysis  Support  System  (LASS)  upgrades  the  DMA  Image  Exploitation  Facility  (lEF)  to  provide 
DMA  with  the  means  to  create  Landsat  Image  Maps  for  regions  of  the  world  that  are  beyond  the  near  term 
DMA  production  plans. 


The  image  mapping  capability  of  the  lEF/LASS  is  based  on  the  facilities  provided  b'’  the  Land  Analysis 
System  (LAS)  software  package.  LAS  is  an  image  analysis  system  developed  cooperatively  by  the 
Goddard  Space  Flight  Center  (GSFC)  and  the  USGS  EROS  Data  Center  (EDC).  The  Land  Analysis 
Support  System  provides  digital  image  processing  capabilities  that  are  necessary  to  convert  Thematic 
Mapper  (TM)  data  input  on  computer  compatible  magnetic  tape  to  proof  plots  and  data  output  on 
computer  compatible  magnetic  tape  for  eventual  production  as  Landsat  Image  Maps.  Figure  2-1  depicts 
this  image  mapping  process  and  LASS’S  pan  in  that  process. 


Data  Acauisition  Radiommric  Restoration  Digital  Image  Processing 


Color  Proofing 

Contact  Neganves  Color  Fire 


Printing  Plates 
Uthograpned  Image  Maps 


Scan  of  Film 
Positivos  and 
Production  of 
Halftone 
Separations 


Figure  2-1  The  Image  Map  Production  Process 


The  image  mapping  process  begins  with  data  acquisition  and  the  processes  of  radiometric  restoration  and 
scene  selection.  These  steps  take  place  at  EOSAT  and  EDC.  The  image  mapping  process  continues 
with  input  to  the  digital  image  processing  capabilities  provided  by  the  LASS  in  the  form  of  computer 
compatible  taoes.  Output  from  LASS  is  in  the  form  of  proof  plots  (from  the  Kodak  printer)  and  computer 
compatible  tapes.  Magnetic  tapes  created  for  input  to  a  SCITEX  system  are  created  with  four  separations 
that  will  eventually  become  the  cyan,  magenta,  yellow,  and  black  process  color  pnnting  plates.  Creation  of 
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halftone  separations,  that  then  undergo  color  proofing,  creation  of  contact  negatives  and  printing  plates, 
and  production  of  image  maps  via  color  lithography,  takes  place  on  the  SCITEX  system.  Magnetic  tapes 
may  also  be  created  for  input  to  a  Color  Fire  240  Printer,  which  also  requires  the  generation  and  scanning 
of  film  positives  prior  to  the  creation  of  halftone  separations. 


% 
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SECTION  3. 


SYSTEM  DESIGN 


The  impiementation  of  LASS  image  mapping  capabilities  required  modifications  to  the  existing  lEF/RWPF 
hardware  and  software  configuration,  the  addition  of  a  proof  plot  generation  capability  based  on  a  Kodak 
Continuous  Tone  Digital  Image  Printer,  and  the  development  of  software  to  generate  image  map  data  in  a 
computer  coin^atibie  magnetic  tape  format  that  can  be  read  into  SCITEX  systems.  These  activities  are 
described  in  greater  detail  in  the  following  sections. 

3.1.  lEF  Modifications 


In  order  to  install  LAS  on  the  lEF  a  variety  of  modifications  to  the  lEF  hardware  and  software  configurations 

« 

were  required.  Modifications  were  made  to  the  VAX-i  1/785  processor,  the  Gould/De Anza  image 
processing  display  system,  and  to  the  Sun-2/i70  workstations.  Figure  3-1  is  a  schematic  diagram  of  the 
current  lEF  hardware  configuration  following  these  modifications. 


1024  X  1024 
Color  Monitor 

1024  X  1024 
Color  Monitof 

1  r  btereo  viewer)  { 

Matnx 

1024X  102^ 
Camera 


nUUBaUNQBBW 
I  512x512  S 
J  Color  Monlto^ 


Figure  3-1  Current  lEF  Hardware  Configuration 
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3.1.1. 


VAX-11/785 


LASS  modifications  were  most  extensive  on  the  VAX-11/785  processor.  Modifications  included 
additional  hardware  and  new  operating  system  software,  details  of  which  are  provided  below. 

System  memory  on  the  VAX-l  1/785  was  upgraded  from  8  to  64  megabytes  to  support  the  large  image 
formats  typical  of  DMA  image  processing.  The  memory  upgrade  was  accomplished  by  replacing  the  eight 
(8)  1  megabyte  memory  boards  used  on  the  prior  lEF  configuration  with  eight  (8)  8  megabyte  memory 
boards  from  Clearpoint  Research  Corporation  to  provide  64  megabytes  of  memory.  Sixty  tour  megabytes 
is  the  maximum  amount  of  memory  that  the  VAX-11/TO5  processor  supports. 

Two  Winchester  disk  drives  were  added  to  the  configuration  each  with  an  additional  780  (660  formatted) 
megabytes  of  disk  space,  to  accommodate  the  on-line  storage  and  manipulation  oi  large  image  data 
collections. 

LASS  proof  plot  generation  is  provided  by  a  KODAK  color  printer.  Details  about  the  installation  and 
integration  of  the  proof  plotting  capability  are  provided  in  Section  3.3. 


Figure  3-2  illustrates  the  current  physical  layout  of  the  lEF/VAX  hardware  configuration.  This  layout  was 
constrained  in  part  by  the  maximum  permissible  cable  lengths  and  the  locations  of  available  Unibus 
connections. 


Figure  3-2  lEF/VAX  Hardware  Layout 

The  most  recent  version  of  the  Digital  Equipment  Corporation  (DEC)  VAX/VMS  operating  system,  VMS 
5.3.  was  installed  on  the  lEF.  The  LAS  software  package  requires  the  VMS  operating  system.  To  support 
compiling  the  LAS  package  and  to  provide  support  for  the  development  and  installation  of  the  Scitex 
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conversion  software,  the  KODAK  Printer  interface,  and  the  VICOM  monitor  device  drivers,  the  most 
recent  vetsions  of  the  DEC  FORTRAN  and  C  language  compilers  were  also  installed  on  the  VAX-1 1/785. 
A"  software  written  for  the  LASS  corwract  was  written  using  either  the  C  language  or  the  LAS  PDF 
command  tile  language.  DEC  software  licenses  were  registered  with  the  VMS  license  management  facility 
for  the  VMS  operating  system,  and  the  FORTRAN  and  C  compilers. 

Once  all  of  the  above  hardware  and  software  modifications  were  accomplished,  the  VMS  AUTOGEN 
command  procedure  was  executed  to  automar  :alty  tailor  the  system's  operating  system  parameters  to  the 
current  hardware  configuration. 

At  the  recommendation  of  personnel  from  EDC,  the  ten  previously  existing  data  disk  packs  (alt  of  the 
RA60  disk  drives  except  for  the  two  used  to  maintain  the  operating  system  and  LAS  software 
respectively),  and  the  two  newly  integrated  V/inchester  disk  drives  were  'bound'  into  a  single  virtual  disk 
volume  using  the  VMS  MOUNT/BIND  utility.  This  practice  permits  the  LAS  software  and  users  to  use  as 
much  disk  space  as  necessary  to  perform  image  processing  functions  without  the  need  to  be  concerned 
with  developing  an  effective  disk  space  usage  strategy V 

To  ease  the  transition  for  users  already  familiar  with  the  lEF's  former  Unix  environment,  a  publicly  available 
emulation  of  the  Unix  vi  text  editor  (originally  developed  by  Greg  Wonderly,  Mathematics  Department, 
Oklahoma  State  University,  and  obtained  from  the  Usenet  network)  was  installed  in  addition  to  a  number  of 
other  command  procedures  to  provide  'Unix-like'  capabilities  on  the  LASS. 

During  the  course  of  LASS  integration  and  testing  a  number  of  modifications  were  made  to  the  operating 
system  parameters  and  authonzed  user  resource  limits  to  permit  better  utilization  of  the  lEF  environment. 
Most  of  these  modifications  were  performed  using  the  DEC  AUTOGEN  facility  mentioned  above. 
However,  the  KODAK  interface  software  required  that  the  SYSGEN  VIRTUALPAGECNT  parameter  be 
increased  in  order  to  build  and  use  the  KODAK  interface  software.  Also,  the  working  set  parameters 
associated  with  user  accounts  were  increased  to  permit  better  use  of  the  increased  available  memory  by 


^  PGSC  personnel  recommerxled  against  this  disk  binding  because  of  the  potential  problems  that  can 
result  should  one  of  the  individual  disk  drives  or  disk  packs  fail,  especially  considering  the  relative 
unreliability  of  the  RA60  disk  packs  as  compared  to  fixed  disk  technology.  Should  one  of  the  disks  in  a 
virtual  disk  volume  suffer  a  disk  crash  or  intermittent  failure,  the  entire  virtual  disk  volume  is  essentially 
corrupted.  Due  to  the  time  required  to  create  a  backup  copy  of  the  virtual  disk  contents,  approximately  an 
hour  per  disk  pack,  there  is  no  effective  way  to  create  a  recoverable  duplicate  of  the  virtual  disk  contents. 
PGSC  recommended  that  the  two  Winchester  disk  dnves  be  used  as  one  virtual  disk  ana  the  ten  RA60 
disk  drives  be  bound  into  a  second  virtual  disk,  in  that  way.  should  one  of  the  virtual  disks  become 
corrupted,  at  least  limited  production  could  continue  on  the  other  while  repairs  are  initiated.  Relatively 
simple  disk  usage  strategies  could  be  developed  to  balance  the  load  on  either  virtual  disk. 
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memory'intensive  image  processing  tasks.  The  working  set  size  increases  were  performed  following 
analysis  of  image  accounting  statistics  and  working-set  sizes  during  LAS  testing.  Changes  to  the  user 
account  parameters  were  incorporated  into  a  VMS  command  procedure.  ADDUSER.COM,  to  automate 
the  procedures  involved  in  creating  new  user  accounts.  Often  used  LAS  executable  image  files,  which 
were  identifiec  through  analysis  of  image  accounting  statistics,  were  installed  as  sharable  VMS  images  to 
enhance  system  performance. 

3.1.2.  Gould/DeAnza  Workstations 

Modifications  to  the  Gould/DeAnza  workstations  were  necessitated  by  the  need  to  provide  display 
monitors  supported  by  the  current  capabilities  of  the  LAS  software  package.  Two.  low  resolution 
(512x512)  monitors  were  acquired  from  VICOM  in  addition  to  the  current  VICOM  Systems  inc..  supponed 
device  driver  .ind  diagnostic  software.  The  VICOM  device  drivers  and  the  diagnostic  software  were 
installed  on  the  VAX’s  system  disk.  This  software  was  configured  to  be  loaded  at  system  stanup  and  made 
accessible  to  the  LAS  package  as  the  LAS  devices  LORESi  and  L0RES2.  Details  on  this  configuration 
can  be  found  m  the  LASS  Operations  Manual. 

The  physical  location  of  the  512x512  monitors  in  the  Gould/DeAnza  workstations  was  an  issue  with  four 
possible  options: 

•  Installation  of  both  512x512  monitors  in  place  of  the  stereo  workstation's  two  1024x1024 
monitors. 

•  Installation  of  one  512x512  monitor  in  place  of  one  1024x1024  monitor  on  the  stereo 
workstation  and  installation  of  the  oth^er  512  x  512  monitor  m  place  of  the  1024  x  1024 
monitor  on  the  mono  workstation. 

•  Installation  of  the  512x512  monitors  in  place  of  the  current  status  display  monitors  on 
each  workstation. 

•  Installation  of  the  512x512  monitors  on  the  work  table  surface  of  each  workstation. 

The  first  three  options  were  rejected  because  they  would  have  impacted  the  Unix  system's  capabilities 
unduly,  would  have  necessitated  acquiring  rack  mounts  for  the  low  resolution  display  monitors,  and  would 
not  have  adapted  well  to  the  standard  LAS  requirement  for  a  single  display  allocated  to  each  user.  The 
fourth  option,  installation  of  the  display  monitors  on  the  workstation  taole  tops,  avoids  those  impacts  and 
facilitates  operator  interaction  with  the  displays.  The  latter  is  most  important  during  control  point  selection 
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in  support  of  the  image  mosaicking  procedures  where  the  operator  must  be  as  close  as  possible  to  the 
display. 

3.1.3.  SUN-2/170 

The  SUN2  wor<statjons  that  are  connected  via  Ethernet  to  the  VAX-l  t/785  processor  are  net  able  to  use 
the  Ethernet  for  inter-processor  communication  as  is  possible  in  the  Unix-based  lEF  configuration. 
Common  soft^^are  communication  protocols  are  required  to  use  the  Ethernet  in  this  manner.  The 
standard  VMS  and  SUN2  operating  systems  do  not  support  a  compatible  Ethernet  communication 
protocol.  As  an  alternative,  to  provide  for  communication  between  the  SUN2  based  workstations  and  the 
VAX-1 1/785  processor,  an  RS-232  terminal  line  interface  was  provided. 

Two  RS-232  cables  were  acquired  and  were  used  to  connect  the  SUNS  to  the  VAX  through  the  SUN2’s 
terminal  ports  and  the  VAX's  D2-11.  The  Sun  workstations  orovide  a  terminal  interface  software  tool,f/p, 
that  provides  the  necessary  hooks  to  enable  a  login,  virtual  terminal  window  on  the  VAX.  The  window  is 
created  from  the  SUN2  consoles.  A  VMS  terminal  definition  file  for  the  SUN  was  ootained  from  EDC  and 
installed.  Although  not  100%  compatible  with  VMS  it  does  allow  lor  l_AS  tutorial  mode  entry  and  limited 
VMS  editor  support.  The  software  required  to  use  the  Ethernet  interface  and  the  benefits  this  would 
provide  to  LASS  operations  are  discussed  in  Section  4. 

3.2.  Kodak  Image  Print 

A  KODAK  XL/700  Digital  Continuous  Tone  color  printer  was  interfaced  with  the  VAX-11/785  to  provide  a 
proof  plot  generation  capability.  The  KODAK  device  drivers  and  the  user  interface  sottware  acquired  from 
Command  Systems  Group  were  installed  on  the  VAX's  system  disk  in  a  directory  wnose  logical  name  is 
KODAK.  The  KODAK  printer  device  drivers  were  configured  to  be  loaded  at  system  startup  and  the  user 
interface  software.  XLPRINT,  was  made  easily  accessible  to  LASS  users  by  creating  an  XLPRINT  symbol 
each  time  a  user  logs  on  to  the  system.  Details  about  the  KODAK  user  interface,  how  it  is  accessed,  and 
how  it  operates  can  be  found  in  the  LASS  Operations  Manual. 

3.2.1.  Kodak  Calibration 

In  order  to  assure  consistent  colors  between  the  various  image  output  devices  supported  by  the  LASS 
configuration  (Scitex  compatible  magnetic  tape,  Kodak  printer,  DeAnza  monitor)  a  procedure  has  been 
developed  to  aid  in  the  calibration  of  devices.  The  calibration  starts  with  output  from  a  designated  device 
that  is  considered  to  be  calibrated  and  works  backwards  to  form  color  correction  tables  for  other  devices. 
The  USGS  Scitex  system's  laser  plotter  was  selected  as  the  baseline  calibration  device.  Because  low  to 
high  saturation  rates  of  colors  on  different  output  devices  vary,  a  color  correction  table  between  fixed  grey 
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intensity  levels,  was  defined  to  approximate  saturation  rates  between  devices.  Color  correction  tables 
were  created  for  each  device  by  performing  a  comparison  of  color  wedges  generated  by  the  device. 

3.3.  Scitex  Conversion 

Software  was  prepared  to  enable  the  generation  of  image  map  data  on  computer  compatible  magnetic 
tapes  that  can  be  input  to  Scitex  systems.  During  the  course  of  development  and  testing  of  this  software, 
two  Scitex  systems  were  used  as  targets  for  validating  this  capability;  the  Scitex  system  at  the  U.S. 
Geological  Survey's  Eastern  Mapping  Center  in  Reston,  Virginia,  and  the  Scitex  system  at  OMA-AC  in  St. 
Louis.  Missouri.  Software  to  generate  two  formats  were  prepared  to  deal  with  the  fact  that  not  all  Scitex 
systems  are  able  to  read  and  interpret  the  Scitex  data  import  format  known  as  Handshake  format.  The 
Scitex  at  OMA-AC  can  read  and  interpret  Handshake  format,  the  Scitex  at  USGS-EMC  cannot. 

The  generation  of  image  data  in  a  format  not  requiring  Scitex  Handshake  caoabiiities  uses  existing 
capabilities  of  the  LAS  software  package.  The  LAS  TAPEOUT  function  has  options  to  produce  a 
magnetic  tape  format  that  can  be  read  by  Scitex  systems.  Importation  of  this  data  on  a  Scitex  system 
requires  that  the  data  be  passed  a  single  band  at  a  time,  necessitating  effort  on  the  Scitex  system  to 
create  an  image  tile  with  all  four  (cyan,  magenta,  yellow,  and  black)  bands  interleaved.  In  addition, 
information  about  the  pixel  size  and  map  scale  to  be  used  by  the  Scitex  color  separation  plotting 
capabilities  must  be  manually  transmitted  to  the  Scitex  operators. 

A  LAS  PDF  (command  file)  was  prepared  to  aid  lEF/LASS  users  in  following  the  steps  of  adding  a 
calibration  color  bar  to  images;  converting  the  images  to  cyan,  magenta,  yellow,  and  black  process  color 
separations;  stretching  the  generated  black  band  to  permit  black  overprints  to  be  visible;  and  using  the 
proper  parameters  for  the  LAS  TAPEOUT  function  to  create  a  computer  compatible  magnetic  tape  that 
can  be  read  on  Scitex  systems.  This  LAS  command  file,  USGSSCITEX  PDF,  is  available  to  users  in  LAS 
TUTOR  mode,  providing  a  menu  based,  fill  in  the  blanks,  user  interface  complete  with  on-line  help  for  the 
meanings  of  the  command  file  parameters. 

During  the  course  of  LASS  implementation,  testing,  and  training,  a  variety  of  computer  compatible 
magnetic  tapes  of  LAS  image  data  were  generated  and  read  into  the  USGS-EMC  Scitex  System.  Color 
separation  negatives  were  created  on  the  Scitex  laser  plotter  and  Cromalin  color  proofs  were  created  for 
the  Tingo  Maria  map  sheet  area  and  for  the  Baghdad.  Iraq  area.  The  latter  image  was  created  by  merging 
Landsat  and  SPOT  imagery. 

The  generation  of  Scitex  Handshake  format  on  the  lEF/LASS  permits  the  automatic  transmittal  of  image 
data  in  a  band  inter-leaved  format  and  with  the  desired  final  map  scale  in  a  single  computer  compatible 
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magnetic  tape  file.  This  method  of  image  data  transmittal  to  the  Scitex  system  precludes  a  number  of  extra 
processing  steps  that  are  required  where  Scitex  Handshake  capabilities  are  not  available. 

A  LAS  command  file,  ACSCITEX.PDF.  provides  the  same  support  as  the  USGSSCITEX.PDF  except  that 
the  newly  developed  HANDSHAKE  function  is  included  to  create  a  computer  compatible  magnetic  tape. 

During  the  course  of  LASS  implementation,  testing,  and  training,  computer  compatible  magnetic  tapes  of 
LAS  image  data  in  Scitex  handshake  format  for  the  Tingo  Maria  map  sheet  area  and  for  the  Baghdad.  Iraq 
area  were  created  and  sent  to  St.  Louis  where  they  were  successfully  read  into  the  OMA-AC  Scitex 
System. 
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SECTION  4. 


SUMMARY 


The  purpose  of  the  LASS  implementation  was  to  provide  DMA  with  the  means  to  create  Landsat  Image 
Maps  by  enhancing  the  capabilities  of  the  lEF.  Analysis  of  the  existing  hardware/software  facilities  of  the 
lEF.  Scitex  systems,  and  the  LAS  software  package  identified  the  integration  requirements  between 
these  three  s  /stems.  The  lEF  was  modified  to  support  these  requirements,  the  LAS  software  was 
integrated  into  the  lEF  environment,  and  interfaces  were  developed  and  integrated  .0  permit  the  output 
of  the  lEF  image  processing  capabilities  to  be  used  as  input  to  Scitex  systems.  In  addition,  a  hanlware 
proofing  device  was  integrated  to  help  insure  correctness  of  image  colors  prior  to  the  creation  of  computer 
compatible  magnetic  tape  output  to  Scitex  systems. 

A  sample  prototype  produa  development  activity  that  was  carried  out  during  the  LASS  imolementation 
was  the  integration  of  contour  information  into  an  image  mao.  Tr.s  oroceoures  invoiveo  m  this  activity  are 
described  in  Appendix  X. 

The  activities  involved  in  implementing  the  lEF/LASS  image  mao  proouction  caoaoilities  were  described 
in  Section  3  of  this  report.  The  use  of  these  facilities  is  described  in  the  LASS  Operations  Manual. 
Additional  details  about  the  hardware/software  integration  and  development,  and  the  capabilities  of  the 
enhanced  lEF/LASS  environment  may  be  found  in  the  LASS  User  Manual. 

4.1.  Recommendations 

During  the  course  of  implementing  LASS  image  mapping  capabilities  info  the  lEF  environment,  a  number 
of  possible  imorovements  to  that  environment  suggested  themselves.  Some  of  those  are  described 
below. 

The  KODAK  proof  plot  generation  capability  utilizes  a  user  interlace  menu  package  developed  by 
Command  Systems  Group.  The  image  data  format  that  is  downloaded  into  the  KODAK  printer  is  easily 
created  in  the  VMS  environment.  It  is  this  format  that  the  user  interface  menu  package  prefers. 
Unfortunately,  the  LAS  data  export  functions  do  not  currently  create  this  format.  At  PGSC’s  request 
Command  Systems  Group  added  support  for  the  data  format  that  LAS  export  functions  create,  however 
this  data  format  is  accessed  much  more  slowly  than  the  KODAK  preferred  format.  A  fairly  easy  task  would 
be  to  create  a  LAS  function  to  generate  the  data  format  preferred  by  the  KODAK  interface  software 
directly  from  the  LAS  internal  format.  This  would  permit  proof  plots  to  be  generated  somewhat  taster  by 
permitting  much  faster  access  to  image  data. 
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An  additional  enhancement  that  would  increase  the  utility  of  the  Kodak  printer  would  be  the  development 
of  a  LAS  function  to  quickly  transform  an  image  which  is  larger  than  the  maximum  KODAK  image  size 
(2Kx2K)  into  a  size  that  would  fit  in  the  KODAK'S  memory. 

The  Sun  console  interface  to  the  LAS/TAE  environment  via  the  RS-232  cables  installed  during  LASS 
implementatiOM  provides  a  simple,  but  not  very  user  friendly,  interface.  Users  are  restricted  to  a  single 
login  window  into  the  VAX  and  are  limited  to  the  transmission  speed  provided  by  the  RS-232  interface. 
Meanwhile  the  Ethernet  interface  still  exists  between  the  SUN2  workstations  and  the  VAX-11/785 
processor,  it  tacks  only  a  compatible  network  protocol  on  the  two  systems  to  enable  an  enhanced  user 
interface. 

The  simplest  solution  to  providing  a  compatible  network  interface  is  to  install  a  VMS  compatible  TCP/IP 
protocol  interla:e  on  the  VAX-i  1/785.  Using  a  TCP/IP  network  protocol,  users  wouio  be  able  to  generate 
many  login  windows  from  the  SUN2  SunWindows  environment  via  the  Unix  telnet  utility.  With  that 
capability,  users  would  be  better  able  to  monitor  the  progress  ot  image  processing  jobs,  manage  disk 
space,  reply  to  requests  to  the  operator  to  mount  and  dismount  magnetic  tapes,  as  examples. 
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APPENDIX  A 


CONTOUR  ENGRAVING 


This  appendix  provides  a  detailed  set  ot  commands  and  explanations  tor  how  to  ponray  contours  on  a 
Landsat  scene  using  existing  LAS  5.0  tools.  This  was  a  prototype  deveiooment  effort,  thus  the 
procedure  is  not  very  elegant  (as  illustrated  by  Figure  A-i)  or  efficient.  Upon  certification  that  the 
prototype  is  a  desired  product,  then  various  optimized  processing  steps  could  be  incorporated  into  the 
procedure.  The  two  most  effective  steps  (illustrated  in  Figure  A-2)  would  be  to  i)  directly  register  either 
the  graphics  overlay  file  or  the  labeled  table  file  containing  the  contours  to  the  final  Landsat  scene  and  2) 
^engrave*  the  contours  onto  the  Landsat  imagery  bands  directly  from  the  graphics  overlay  file. 

The  Gerber  contour  data  obtained  from  the  DMAAC  was  derived  from  DTED  which  was  extracted  from 
SAR  imagery.  The  contours  covered  the  area  from  9°  to  9°30’  South  Latitude  and  from  76°  to  76°30’ 
West  Longitude,  which  is  to  the  west  of  the  central  part  of  Tingo  Marla.  Peru.  Some  information  was 
extracted  or  surmised  from  the  Gerber  tiles'  header,  althougn  that  information  was  never  explicitly  used. 
The  map  projection  is  Transverse  Mercator  (using  -76°15'  longitude  as  the  central  meridian  and  0°  as  the 
pole  of  projection),  the  scale  is  i  100.000.  the  coordinates  are  expressed  in  mils  (O.OOl  inch),  and 
elevation  values  are  in  meters.  The  datum  was  not  specified.  It  would  have  been  more  desirable  to  have 
the  contours  generated  by  DMAAC  with  the  same  map  projection  as  used  by  the  Tingo  Maria,  Peru 
prototype  image  map  (e  g.,  the  central  mendian  for  the  Tingo  Maria  sheet  was  -75°  longitude). 

Two  sets  of  contour  data  were  provided,  one  containing  100  meter  contour  intervals,  the  other  containing 
500  meter  contour  intervals.  Only  the  500  meter  contour  intervals  were  processed  during  the  prototype 
study. 

Two  additional  study  areas  related  to  the  presentation  of  contours  on  the  image  maps  include  portrayal  of 
maximum  elevation  values  in  grid  cells  and  contour  labeling. 

•  The  contour  labels  associated  with  the  contours  used  for  this  study  are  available,  but 
additional  study  is  needed  to  resolve  how  to  extract  them  accurately  from  the  Gerber 
plotter  commands.  Each  label  has  a  position  and  rotation  value,  relative  to  the  lower  left 
corner  of  the  label  text.  The  association  of  the  label  to  a  specific  contour  is  then 
dependent  on  the  font  size  and  the  angle  of  rotation.  It  would  be  desirable  to  work 
directly  with  contours  which  have  elevation  values  associated  with  them  as  attributes, 
instead  of  surmising  that  information  from  plot  data.  The  uncertainties  associated  with  the 
plot  data  are  magnified  by  the  processing  methodology  used  within  the  LAS 
environment.  Some  ot  the  processing  performed  on  the  graphics  generated  by  the 
contours’  spatial  coordinates  wiil  not  work  for  contour  labels. 
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Figure  A-i  Generating  Landsat  contour  images  using  existing  LAS  tools. 
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Figure  A-2  Recommended  production  process  for  generating  Landsat  contour  images 
using  new  LAS  and  specialized  software  tools. 
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•  Maximum  elevation  values  can  be  extractea  from  the  DIED.  The  procedure  would 
consist  of  registering  the  DIED  (which  can  be  read  into  the  LAS  environment  by  standard 
LAS  5.0  funaionsi  to  the  Landsat  scene.  LAS  tools  permit  extracting  the  maximum 
values  within  a  graphics  overlay  polygon.  If  polygons  are  defined  to  be  the  desired  grid 
cells,  then  the  maximum  elevation  can  be  determined  “interactively"  for  each  of  the  grid 
cells.  1  hat  information  could  then  be  placed  in  a  graphics  overlay  point  file  with  each  label 
defined  as  the  maximum  elevation.  The  placement  of  the  label  is  somewhat  related  to  the 
position  defined  by  the  point  feature.  Unfortunately,  LAS  would  illustrate  the  point 
feature  as  a  point,  thus  incorrectly  implying  that  the  elevation  value  is  related  to  that 
specific  position  and  not  the  entire  grid  cell. 

The  following  ciscussion  otien  includes  file  names  m  the  commands.  These  are  intended  to  illustrate 
where  some  of  the  existing  input  and  resulting  cutout  tiles  are  currentiv  located.  Care  snouid  be  taken  to 
avoid  destroying  a  tile  that  was  created  from  time  consuming  processing. 

A,  1  Read  Gerber  Plot  Formatted  Tape  from  DMAAC. 

OMA-AC  provided  two  sets  of  contour  data  covering  the  Tingo  Maria  area,  with  each  set  consisting  of 
three  files.  The  first  file  has  contour  spatial  information,  the  second  has  contour  label  information,  and  the 
third  has  the  grid  line  ana  soot  elevation  information.  The  Gerber  files  were  read  using  the  "gerbeiTead" 
function  on  an  ARC/INFO  system  (in  the  Unix  environment).  The  files  were  then  "tarred"  to  tape, 
extracted  from  the  tar  tape  m  another  Unix  environment  at  PGSC’s  Reston  facility,  manipulated  and  written 
back  to  tape  in  a  VMS  compatible  format,  and  then  extracted  from  tape  in  the  lEF  VAX/VMS  environment. 

A. 2  Edit  the  Gerber  files 

All  three  files  have  header  type  of  information  consisting  of  plot  instructions  about  product  name,  product 
type,  projection,  scale,  contour  interval,  etc.  These  headers  also  contain  “sign-off"  lines  for  the  vanous 
levels  of  management  and  cartographic  supervisors.  These  are  found  in  the  header  as  the  lines 
immediately  following  the  text  "CHART  The  sign-off  lines  consist  of  the  commands  pen  up  and  move 
to  a  location,  pen  down  and  move  to  another  location,  pen  up  and  move  to  a  third  location  to  place  the 
label  of  who  should  initialize  the  plot.  Unfortunately,  these  commands  will  become  confused  with  that  of  a 
contour,  it  is  more  economical  to  fix  the  data  using  an  editor  than  to  vyrite  specialized  software  to  handle 
this  case.  The  fix  is  to  either  delete  that  portion  of  the  text,  or  put  a  GOl  in  front  of  the  DOi  and  the  2*^^ 
D02  codes.  In  this  manner  the  next  processing  step  will  ignore  the  spatial  coordinates  for  the  output  files. 
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At  the  very  end  of  the  contour  tile,  the  last  contour  begins  with  the  pen  up  ana  pen  down  sequence  for 
the  first  two  coordinates.  It  also  has  a  pen  up  (002)  for  the  very  last  cooroinate  wmch  is  a  value  totally 
unrelated  to  the  contour.  Use  the  eoitor  to  put  a  G01  code  in  front  of  the  X  preceding  this  002. 

The  final  problem  area  penains  to  the  grid  lines.  The  grid  lines  are  plotted  on  the  Gerber  plotter,  in  the 
case  of  the  files  received,  as  a  single  set  of  pen  up  and  pen  down  commands.  The  “initializer'  code  of 
G01  is  used  only  at  the  first  coordinate.  Although  they  would  appear  correctly  on  the  Gerber  plotter,  the 
LAS  conversion  software  would  treat  the  ihformation  as  a  single  entity,  and  the  lines  which  join  the 
segments  of  the  grid  lines  would  also  be  visible.  The  action  that  is  needed  is  to  insert  the  GOi  code  in 
front  of  each  grid  line  segment.  This  could  be  accomplished  by  searching  for  "DOi"  and  inserting  “*G01" 
after  the  “DOi ".  (Do  that  operation  8  times.) 

A. 3  Create  Labeled  Table  Files  for  Future  GOF 

Use  the  program  ger2tb|2  and  the  command  file  user:(mikeg.g2t]rung.com.  "he  command  file 
"lanoies  some  of  the  dialogue  for  tile  names  that  are  then  passed  to  the  orogram  ger2tbl.  The  command 
file  then  executes  the  program  with  the  names  as  command  line  arguments;  thus,  a  symbol  for  the 
executable  is  needed: 

g  tss  usert(mikeg.g2t]ger2tbl  . 

The  program  is  currently  hardwired  to  divide  each  coordinate  by  two^  because  LAS  cannot  handle 
cooroinate  values  in  excess  of  20000.  and  the  data  set  at  itand  exceeds  that  vaiue. 

There  are  three  files  outout  to  the  rung.com  command  file  procedure: 

1 .  The  labeled  table  attribute  file,  using  the  2^^  argument  provioed  to  rung.com.  The  file 
name  should  be  of  the  form  <name>.it. 

2.  The  labeled  table  coordinate  file,  using  the  2^^  argument  provided  to  rung.com  with  the 
character  1  appended  to  it. 

3.  A  summary  of  the  number  of  coordinates  contained  for  each  contour,  and  the  “contjnd" 
attribute  value  of  CONTINUOUS  or  BROKEN.  This  output  will  go  to  the  file  specified  by  the 


2ger2tbl  is  made  up  of  the  following  modules;  ger2tbl.c  (mam).  ger2tbl_att.c.  ger2tbl_xy.c,  and 
ger2tbl_prsxy.c. 

-Yes.  hardwired,  but  in  module  ger2tbl_hal(xy.c  with  entry  point  of  ger2tbl_prsxy().  Not  the  best 
software  engineering  method,  but  it  was  needed  to  get  past  the  initial  LAS  obstacle  of  discovering  how  to 
work  with  graphics  overlay  files  in  LAS 
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3'^^  argument:  if  it  is  blank,  and  remains  so  after  the  command  file  queries  for  it.  then  the 
output  goes  to  the  terminal. 

An  explanation  of  the  CONTINUOUS  or  BROKEN  attribute:  If  a  contour  (i.e.,  spatial  coordinate  stream) 
has  one  pen-up  and  one  pen-down  code,  then  it  is  declared  as  CONTINUOUS.  If  it  has  more  than  one  of 
either  pen-up  or  pen-down  codes,  then  it  is  declared  as  “BROKEN".  (More  about  this  later,  in  SHOGOF.) 

A. 4  Create  Two  Labeled  Tables:  Grid  and  Contour 

Use  the  first  of  the  3  Gerber  files  to  create  the  labeled  tables  for  the  contour  spatial  information  to  be 
loaded  into  a  Graphics  Overlay  File.  Use  the  third  of  the  3  Gerber  files  to  create  the  labeled  tables  for  the 
geographic  gnd  to  be  loaded  into  another  Graphics  Overlay  File.  Both  are  needed,  even  though  the  grid 
is  not  of  interest  tor  the  final  image  /  contour  scene.  The  grid  is  essential  for  determining  the  range  of 
coordinate  values  which  will  eventually  be  used  to  spatially  register  contours  to  the  image  scene. 
Illustration  of  the  commands  for  some  specific  file  names: 

(3user:[mlkeg.g2t]rung  grdSOO.gbr  halfgrld.lt  grid. sum 
(§>user:[mlkeg.g2tlrung  conSOO.gbr  halftlngo.lt  halftingo.sum 

where  grdSOO.gbr  and  conSOO.gbr  represent  the  names  of  the  Gerber  formatted  data  files  (for  the  SOO 
meter  interval  data),  halfgrid.lt  and  halftingo.lt  are  the  output  file  name  stems,  and  grid.sum  and 
halftingo.sum  are  the  summary  file  names  for  grid  and  contour  cases  respectively.  To  use  files  already 
cleaned  up"  by  the  editor,  use  (mikeg.gridexpjgridSOO.mjg  and  [mikeg.500contjc500.gbr  instead  of  the 
files  grdSOO.gbr  and  conSOO.gbr,  respectively. 

A. 5  Create  GOF  for  Grid  and  Contour  Gerber  Data 
• 

Now  IS  the  time  to  convert  the  data  to  the  LAS  environment.  After  entering  LAS,  the  PDF  to  be  used  is 
called  tab2gof,  which  converts  a  labeled  table  pair  of  files  to  the  LAS  staictured  <name>.GOF_LiNE 
file.  The  following  illustrates  the  commands: 

tab2gof  Initshalfgrid  outgofshalfgrid 
tab2gof  Initshalftingo  outgof=halftingo 

where  the  first  argument.  halfgridSOO  and  halftingoSOO,  contains  the  labeled  table  name  stems  (as  used 
by  the  @user:(mikeg.g2t]rung  command  above),  and  the  second  argument  is  used  to  form  the  files 
halfgrid.GOF_LINE  and  halftingo.GOF_LINE. 

A. 6  Allocate  the  display 

The  disDiay  must  be  allocated  before  the  next  step  is  performed.  The  command  is  simply  either 
alloc  <display_name> 
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or 

alloc  <dlsplay_nafne>  no 

where  <display_name>  is  either  lorest  or  tores2.  It  is  important  to  note  that  if  the  first  command  is  used, 
any  ARL  files  in  the  directory  will  be  deleted,  whereas  the  second  one  will  not  cause  the  deletion.  If  the 
last  session  cn  LAS  was  at  a  different  workstation,  saving  the  ARLs  will  not  be  useful  because  they  will 
have  the  wrong  name. 

A. 7  Load  Active  Records  List  (ARL)  File  for  Grid  and  Contour  GOF  files 

Before  the  graphics  could  be  plotted,  the  ARL  must  be  created.  The  command  with  possible  file  names: 
lodgot  ttypeallne  Inflleahalfgrld  arlflle=grld 
lodgof  ftypesllne  Inflleshalfcontour  arlfilescontour 

In  these  cases,  the  input  files  are  halfgird.gof  Jine  and  halfcontour.gof  Jine.  the  output  active  records  list 
files  are  <terminaljd>gfid.line  and  <terminalJd>contour.line. 

A. 8  List  Coordinates  of  Grid  GOF  File 
The  command  is: 

lstgof<arl  ftypesllne  arlfllesgrid  printsip  outformsiong  listfigsyes 

The  goals  are  two  fold:  first,  to  note  the  coordinate  system,  and  second,  to  use  the  coordinates  to 
determine  the  proper  display  parameters  for  later  production  processing. 

Coordinate  system:  If  a  coordinate  pair  (a,b)  found  in  the  Gerber  tile,  aixl  also  in  the  labeled 
table  file,  is  examined  in  the  listirtg,  it  will  be  note<  that  it  appears  as  (b.a).  In  the  case  of 
the  Qeiber  Input,  the  coordinate  system  is  'xy',  whereas  in  LAS,  the  coordinate  system  is 
■Vx"  or  “scan  line,  scan  sample'.  The  part  that  is  not  obvious  is  that  the  (1 .1 )  coordinate  in 
the  Gerber  file  is  at  the  lower  left,  while  (1,1)  is  at  the  upper  left  within  LAS.  Thus, 
eventually,  the  coordinates  need  to  be  flipped  top  to  bottom. 

Display  parameters:  Determine  the  minimum  arvl  maximum  values  used  for  the  erxj  points  of 
the  grid  lines.  That  will  be  needed  to  select  the  “best*  display  parameters  when  viewing 
sub-windows  of  the  grid  and  contour  data  at  the  largest  possible  scale.  In  the  case  of  the 
DMAAC  contours  which  were  scaled  by  a  factor  of  0.5,  the  interesting  values  are: 

(  line,  sample) 

Upper  Left:  (  3195,  84i) 

Lower  Right:  (  14079,  11659) 
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(NU  NS) 


(  10885.  10819) 


A. 9  Display  Graphics  for  Grid  GOP_UNE  fils  (sanity  check) 

The  initial  consnand  is: 

shogof-nolmg  ftypesllne  arlfllssgrld 

After  the  program  performs  some  preliminary  processing,  the  user  is  prompted  for  some  additional 
information.  ITe  appropriate  responses  to  the  ‘LAS-SHODYN>'*  prompts  for  the  first  time  are: 
LA8*SHODYN>  a  !  select 

LAS'SHODYN>  /fype«//ne  I  select  only  line 
LAS-SHOOYN>  atrvals(“eont_lnd:’‘)  •  select  all 
LAS*SHOOYN>  sa  !  save  for  next  time 

LAS'S  HOD  YN>  ru  !  run,  I.e.,  display  those  that  satisfy  the  selection 

criteria 

LAS*SHODYN>  a  !  exit  shogof 

A.  10  Display  Graphics  for  Contour  GOF  file  (sanity  check) 


The  initial  command  is: 

shogof'holmg  ftypesllne  arlfllescontour^ 


^If  there  is  a  problem  with  shogof  ‘bombing",  some  remer^  action  is  required.  It  is  surmised  that  memory 
is  exceeded  because  of  the  large  volume  of  spatial  coordinates,  in  the  past,  the  program  bombs  before 
displaying  the  entire  set  of  contours:  re-executing  shogof  will  continue  to  bomb  at  the  same  file  location 
unless  additional  attributes  are  defined.  For  example,  let  the  first  hurxlred  corrtours  have  the  attribute 
name  and  value  of  0SP:1,  the  second  hundred  have  OSP2.  etc.  (That  could  be  performed  in  the  labeled 
table  attribute  file  for  the  contours;  half4tingo.lt  and  half4tingo.gof_line  are  examples  of  such  an 
implementatton  of  that  strategy).  In  this  manner,  cycle  through  the  attribute  subsets  until  (or  before)  the 
program  bombs,  re-execute  shogof-noimg  and  select  the  appropriate  comour  subsets. 

LAS>  shogof*nolmg  ftypesllne  arlfilescontour 

LAS-SHODYN>  s 

LA8-SHODYN>  ftypesllne 

LA8-SHODYN>  airvalsCdsp-.l  ”) 

LAS-SHODYN>  ru 

LAS-SHODYN>  atrvals(‘‘dsp:2”) 

LAS-SHODYN>  ru 

LAS-SHODYN>  atrvals(‘‘dsp:3”) 

LAS-SHODYN>  ru 


As  in  the  case  of  the  grid  GOF.  additional  interaction  is  required.  A  simple  response  may  be  used  if  the 
“save*  was  used  above: 

LAS-SHOOYN>  s  !  select 

LAS-SHOOYN>  re  !  restore  the  ftype  and  atrval  saved  above 

LAS-SHOOYN>  ru  !  run 

LAS*SHOOYN>  e  !  exit  shogof 

A.  11  Display  Graphics  for  Contour  GOF  (lie  (Improved  sanity  check) 

The  following  two  commands  are  sirrilar  to  the  above.  In  the  above  commands.  GOF  coordinate  (1,1) 
corresponds  to  the  upper  left  comer  of  the  display:  the  following  commands  force  the  minimum  scan  line 
and  sample  coordinates  to  correspond  to  the  upper  left  comer  of  the  display: 

shogof*noling  (type=llne  arlfllesgrid  wlndows(mln_sl,  mln_ss, 
total.ss,  total.sl) 

shogof*noimg  ftypesllne  arifllescontour  window=(mln_sl,  mln_ss,  * 
total_ss,  total_si) 

where 

min.sl  >  minimum  of  the  scan  line  coordinates 
min_ss  >  minimum  of  the  scan  sample  coordinates 

total_sl  »  maximum  of  the  scan  line  coordinates  -  min_.sl  +  1 

total.ss  «  maximum  of  the  scan  sample  coordinates  •  min_ss  i 

A.  12  Create  Contour  Image  to  Register  to  Image  Scene 

There  is  not  an  existing  LAS  mechanism  to  register  a  graphics  overlay  to  an  image.  Thus,  the 
methodology  that  is  necessary  is  to  create  an  image  of  the  contours,  which  is  then  registered  to  the 
desired  image  scene.  There  is  also  no  procedure  within  LAS  5.0  to  convert  from  a  graphics  overlay  to  an 
ima^.  The  procedure  is  then  to  display  a  portion  of  the  graphics  on  the  display  (using  SHOGOF-NOIMG), 
and  then  create  a  512^  image  of  the  graphic  display  using  (FRMDSP).  By  being  judicious  in  the 
specification  of  windows  of  the  graphics  overlay  file,  multiple  images  can  be  generated  and  then 
combined  appropriately  to  yield  an  image  scene  with  a  scale  close  to  that  of  the  Landsat  scene. 


LAS*SHOOYN>  e 
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The  first  step  in  the  process  is  to  compute  the  wirxjow  size  to  be  used  by  SHOGOF.  As  the  Tingo  Maria 
scene  has  dimensions  of  2220  by  2206.  the  appropriate  size  for  the  the  recombined  contour  image  is 
2048  by  2048.  (A  smaller  size  will  yield  excessive  pixel  replication  during  the  registration  process,  which 
wiU  increase  the  contour  tine  weight;  a  larger  size  will  yield  excessive  pixel  drop  out,  thus  degrading  the 
comours  with  discontinuities.)  The  2048^  contour  scene  can  be  obtained  by  creating  a  4  by  4  array  of 
512^  contour  images. 

SHOGOF  scales,  graphics  by  integer  values,  thus  it  is  important  to  determine  the  optimal  contour 
information  that  can  be  displayed.  This  can  be  computed  first  using  the  formula  to  determine  the  scale 
that  SHOGOF  will  use: 

scale  -  max  { integer  ((total_sl  +  2047)  /  2048],  integer  ((total_ss  -«•  2047)  /  2048] } 

The  number  of  scan  lines  and  scan  samples  that  will  fit  on  the  512^  display  is  then  scale  ‘  512.  In  the 
case  of  the  contours  for  the  Tmgo  Maria  area,  the  scale  factor  is  6.  thus  windows  into  the  contour  GOF  file 
should  be  dimensioned  3072^. 

The  procedure  is  then  to  display  the  graphics  overlay  file  16  times  using  SHOGOF  with  the  appropriate 
spatial  window;  note  that  each  execution  of  SHOGOF  must  be  preceded  by  a  clean  display,  and  followed 
by  creating  an  image  file  with  a  meaningful  name.  Although  thi:!  is  a  simple  concept,  it  has  the  potential  for 
operator  error.  To  ensure  that  the  process  be  performed  in  as  operator  error  free  mode  as  possible,  a  DCL 
command  file  (called  LOOP)  was  created  to  eliminate  numerical,  typographic  and  file  naming  errors.  It 
simply  creates  a  PDF  which  will  perform  the  16  operations,  followed  by  combining  the  16  images  into  a 
single  2048^  contour  image. 

The  following  commands  should  be  performed  (in  the  VMS  environment,  not  LAS)  for  both  the  grid  and 
contour  graphics  overlay  files.  As  mentioned  before,  the  usefulness  of  the  grid  file  is  simply  for 
registration  purposes.  The  industrious  user  might  prefer  to  compute  the  coordinates  instead  of  selecting 
them  from  the  display,  thus  saving  30-40  minutes  of  processing  time.  (This  ‘loop”  command  file  is 
tiaidwired”  to  the  Tingo  Maria  contour  tile.  It  uses  the  min_sl  and  min_ss  values  from  that  specific  grid  file, 
it  assumes  4^  images  to  form  an  output  of  2048^.  It  should  be  generalized  if  other  contour  files  are  used 
or  different  output  dimensions  are  desired.) 

@user:[mikeg.gridexp]loop  3072  grid  grid3072 

@user;[mlkeg.grldexp]loop  3072  contour  contour3072 
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The  first  argument  is  the  window  into  GOF.  the  secornl  argument  defines  that  ARL  file,  and  the  third 
defines  the  output  PDF  file  (which  will  have  “.pdf“  appended  to  it).  A  copy  of  the  grid3072.pdf  and 
corttour3072.pdf  files  are  attached.  Then.  In  the  LAS  environment,  simply  type  the  name  of  the  PDF; 

grld3072 

contour3072^ 


Unfortunately,  interactive  responses  are  still  required.  Those  responses  are  to  tne  “LAS-SHODYN>" 
prompts.  For  the  first  display  window,  the  responses  are: 

LAS-SHODYN>  s  !  select 

LAS*SHODYN>  ttypesttne  !  select  only  line 

LAS*SHOOYN>  atrvat=(“cont_lnd:cQntlnuous")  !  select  only  those  with 

the  continuous  attribute  ^ 

LAS*SHOOYN>  sa  !  save  for  next  time 

LAS*SHOOYN>  ru  !  run,  I.e.,  display  those  that  satisfy  selection 

criteria 

LAS<SHODYN>  e  !  exit  shogof 


Subsequent  windows  need  the  simpler  responses: 


LAS*SHOOYN>  S 
LAS-SHOOYN>  re 
LAS-SHOOYN>  ru 
LAS*SHODYN>  e 


!  select 

!  restore  the  ftype 
!  run 

!  exit  shogof 


and  atrvai  saved  above 


After  all  16  images  are  created,  the  PDF  will  proceed  to  combine  them  into  the  2048^  scene,  with  the 
image  file  name  defined  by  <2^*^  argumentxfSf  argument>.  The  intermediate  image  files,  history  files, 
and  DDR  files  (with  name^  <2^^^  argumentxl®*  argument>_nm)  should  be  deleted  after  it  is  verified 
that  the  larger  scene  was  generated  correctly. 


SApproximately  3  hours  are  needed  to  execute  this  PDF.  (Approximately  10  minutes  for  each  of  the  16 
scenes  with  some  additional  time  to  combine  them  all  together.) 

®lt  was  noted  that  those  contours  with  attribute  values  of  “cont_ind:broken”  are  redundant  versions  of 
some  contours  with  “cont_ind:conttnuous”,  with  some  spatial  alignment  discrepencies.  It  seemed 
adequate  to  simply  display  those  contours  that  were  “continuous". 
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A.  13  Rsgisttr  the  Contour  Image  to  the  Landsat  Image 


The  next  step  is  to  register  the  contour  to  the  image  scene.  The  4  comer  points  of  the  grid  are  measured 
by  various  LAS  functions.  It  could  be  performed  via  an  interactive  session  with  the  image  and  the 
contours  botfi  di^layed,  but  that  is  unnecessary.  The  approach  that  is  simpler  is  to  select  a  portion  of  the 
image  and  then  to  zoom  in  and  select  a  grid  comer  point.  The  following  illustrates  this: 
todso  ins‘‘grld3072(1, 1,512,512)*’ 
zoomcur 

todao  lns“grld3072(1,1 537,512,512)** 
zoomeur 

todsp  ln=“grld3072(1 537, 1,51 2,512)" 
zoomcur 

todsp  In=“grld3072(1,1,512,512)’* 
zoomcur 

(After  each  zoomcur  command,  select  UL.  UR.  LL.  and  LR  coordinates  of  the  grid,  respectively:  e.g., 
(1,2),  (1,1802),  (1814,1),  and  (1814,1804)  for  the  Tingo  Maria  contours.) 

Next  perform  the  registration  of  the  contour  image  (contour3072)  to  the  image  scene  by  using  EDITTIE, 
POLYFIT,  and  GEOM  LAS  functions^.  When  using  EDITTIE.  remember  that  the  upper  left  (UL)  grid 
coordinate  is  to  match  the  lower  left  (LL)  image  coordinate.  UR  grid  •>  LR  image.  LR  grid  ->  UR  image,  and 
LL  grid  •>  UL  image. 

A.  14  Review  the  Results  of  the  Registration 

Revievr  the  results  by  various  LAS  display  tools:  TODSP,  SCAN,  or  WINDOW.  Some  examples: 
window  Ins"reg_contours3072  +  tlngo7” 

todsp  ins"reg_contours3072(256,256,5i2,5l2)  tingo4(256, 256, 512,512)" 

scan  reg_contours3072 

A.  15  Combine  the  Image  Contour  with  Landsat  Image  Scene 

This  step  “engraves"  the  contour  image  onto  the  Landsat  scene  so  that  the  contours  appear  yellow  on 
the  image. 


^Some  relevant  parameters:  no  correlation,  i^t  order  transfomation,  image  is  the  reference  scene,  grid  is 
the  sample  scene,  inverse  transformation,  nearest  neighbor  resampling.  The  Tingo  scene  has  2220  scan 
lines  and  2206  samples. 
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concat'inanual  inB(tlngo7  rag.contoura)  outst7_cont3072 
SL«(1  1)  SSs(1  1)  NLs2220  NSs2206  4- 
maskvals(0  0)  overopts(repiac  replac) 

coneat«manuai  lns(tlngo4  reg.contours)  outst4_cont3072  -f 
SLs(1  1)  SSs(1  1)  NLs2220  NSs2206  * 
maakvals(0  0)  overopts(replae  raplac) 

map  lnBreg_contours3072  outsneg_reg_contours  ••• 
froms(0  255)  tos(255  0) 

eoneat>manual  in=(tlngo2  neg_reg_contours)  outst2_cont3072  + 

SLs(1  1)  SSs(1  1)  NLs2220  NSs2206  -k 
maskvals(0  255)  overopts(replac  repiac) 

A.  16  Review  the  Final  Images  and  Output  Them  to  Hardcopy  Device 

The  resulting  three  (single  band)  images,  t7_cont,  t4_cont.  and  t2_cont.  correspond  to  the  red,  green, 
and  blue  bands,  respectively.  They  should  be  reviewed  together  or  individually  with  TODSP,  WINDOW, 
and  SCAN  for  final  quality  control.  Some  examples: 

window  lns“t7_cont  +  t4_cont  ♦  t2_cont” 

todsp  lns‘*t7.cont(256,256,512.512}  t4_cont(256,256,51 2,51 2)” 

scan  t2_cont 

These  may  then  be  used  for  display  purposes,  or  for  output  to  the  Kodak  printer  or  Scitex  Plotter. 
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Rome  Laboratory  plans  and  executes  an  interdisciplinary  program  in  re¬ 
search,  development,  test,  and  technology  transition  in  support  of  Air 
Force  Command,  Control,  Communications  and  Intelligence  (C^I)  activities 
for  all  Air  Force  platfc^ms.  It  al^  executes  selected  acquisition  programs 
in  several  areas  of  expertise.  Technical  and  engineering  support  within 
areas  of  competence  is  provided  to  ESD  Program  Offices  (POs)  and  other 
ESD  elements  to  perform  effective  acquisition  of  C^I  systems.  In  addition, 
Rome  Laboratorys  technology  supports  other  AFSC  Product  Divisions,  the 
Air  Force  user  community,  and  other  DOD  and  non-DOD  agencies.  Rome 
Laboratory  maintains  technical  competence  and  research  programs  in  areas 
including,  but  not  limited  to,  communications,  command  and  control,  battle 
management,  intelligence  infwmation  processing,  computational  sciences 
and  software  producibility,  wide  area  surveillance/sensors,  signal  proces¬ 
sing,  solid  state  sciences,  photonics,  electromagnetic  technology,  super¬ 
conductivity,  and  electronic  reliabUity/maintainability  and  testability. 


